---
title: Check and cache AD resource authorization
summary: Determines whether the current principal has access to a caller-supplied AD resource name, caching the result per instance.
status: draft
owner: SAIF BOF documentation team
last_reviewed: 2026-08-21
library: SAIF.Application
reference_type: embedded
operation_id: OP-APP-003
trigger: Concrete subclass of UserAccess calls HasAccess(inResourceName) or CheckAccess(...)
---

# Check and cache AD resource authorization

This operation checks whether the current security principal is authorized for a caller-supplied AD resource name and caches the result for the life of the `UserAccess`-derived instance.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-APP-003 |
| **Trigger** | Concrete subclass of `UserAccess` calls `HasAccess(inResourceName)` or `CheckAccess(ParamArray inResourceName As String())` |
| **Inputs** | `inResourceName` (string), an associated `clsSecurityPrincipal` (set via `SetPrincipal`) |
| **Outputs** | Cached boolean authorization result |
| **Primary components** | `UserAccess.HasAccess`, `UserAccess.CheckAccess`, `UserAccess.SetPrincipal` |
| **Entry point** | `SAIF.Application\UserAccess.vb` |

## Steps

1. Concrete subclass of `UserAccess` calls the protected `SetPrincipal(inPrincipal)` to associate a `clsSecurityPrincipal`. No business rule is enforced at this step and no SQL/table access occurs.
2. Caller invokes `HasAccess(inResourceName)`. If the resource name (lower-cased) is already present in the internal `m_AccessControl` cache, the cached boolean is returned immediately — no re-authorization call is made ([BR-APP-003](../business-rules.md#br-app-003-cached-ad-resource-authorization-result)).
   - If not cached: the method delegates to `clsSecurityPrincipal.IsAuthorized(inResourceName)` (from `SAIF.BOF.Framework`) to obtain the authorization result, caches it in `m_AccessControl`, and returns it.

   > **Origin**: The actual AD-resource lookup is implemented in `clsSecurityPrincipal.IsAuthorized` (`SAIF.BOF.Framework.Security`). The framework's own `IsAuthorized` operation sequence was not resolved via RAG for this run and is not traced further here.**
3. `CheckAccess(ParamArray inResourceName As String())` iterates the supplied resource names and calls `HasAccess` for each, but immediately discards the per-call boolean result into a local `Result` variable that is then reset to `Nothing` and never read or returned.
   - This method has no observable external effect beyond populating the `HasAccess` cache as a side effect; this appears to be dead/ineffective logic in its current form as written.*

## Process flow

The following diagram visualizes this operation's control flow.

```mermaid
flowchart TD
	Start([Caller invokes HasAccess or CheckAccess]) --> S1[SetPrincipal associates clsSecurityPrincipal]
	S1 --> S2{Resource name cached?}
	S2 -->|Yes| S3[Return cached boolean]
	S2 -->|No| S4[Call clsSecurityPrincipal.IsAuthorized]
	S4 --> S5[Cache result in m_AccessControl]
	S5 --> S3
	S3 --> EndOk([Authorization result available])
```

## Failure and edge-case behavior
- `CheckAccess`'s discarded `Result` variable means its only observable outcome is warming the `HasAccess` cache; it is unclear whether this is intentional cache pre-warming or a leftover/incomplete implementation.*
- A cached `HasAccess` result could be stale if the underlying AD membership changes during the instance's lifetime.*

## Related documentation
- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [Security and authorization](../security-authorization.md)
- [API reference](../api/index.md)

> **Note:** Statements marked with `*` were inferred from code structure, naming
> conventions, or contextual evidence where direct confirmation was not available
> in source artifacts. Statements marked with `**` could not be confirmed; treat
> as unknown until verified.

## Sources
- `SAIF.Application\UserAccess.vb`